Row-Level Security and Data Access Management in Tableau

Course: Tableau Training | Topic: Row-Level Security (RLS), User-Based Filtering, Permissions, and Secure Data Access

Explore the course: Explore Tableau Training

Book a demo: Register for a Tableau Course Demo

1. Introduction to Row-Level Security

Row-Level Security (RLS) is a data security technique that restricts which rows of a dataset a user can view. In Tableau, it allows multiple users to work with the same workbook or dashboard while seeing only the records they are authorized to access.

For example, a company may have sales managers in Mumbai, Delhi, Pune, and Bengaluru. All managers can open the same sales dashboard, but each manager should see only the sales records for their assigned region. Row-level security makes this possible without creating a separate dashboard for every manager.

RLS is particularly useful when dashboards contain confidential information such as sales figures, employee records, customer details, financial data, and regional business performance.

Example

Each user can access the same published dashboard, but Tableau applies the configured security rules to determine which rows are visible. Read Tableau's documentation on row-level security.

2. Learning Objectives

After studying this topic, you should be able to:

• Explain row-level security and data access management.
• Differentiate row-level security from workbook and project permissions.
• Understand user-based filters and dynamic security calculations.
• Create a security mapping or entitlement table.
• Use Tableau user functions such as USERNAME(), FULLNAME(), and ISMEMBEROF().
• Understand data-source filters and published data sources.
• Explore virtual connections and data policies for centralized RLS.
• Test security rules for multiple users and groups.
• Apply security best practices to protect sensitive business data.

3. Understanding Data Access Management

Data access management is the process of controlling who can access data, which content they can use, and what operations they are permitted to perform. In Tableau, it involves user identity, site roles, groups, content permissions, data-source access, and row-level security.

3.1 Authentication

Authentication verifies the identity of a user. For example, Tableau may authenticate a user through a username and password, single sign-on (SSO), or another configured identity provider.

3.2 Authorization

Authorization determines what an authenticated user is allowed to do. For example, a user may be allowed to view a dashboard but not edit, download, or delete the workbook.

3.3 Content permissions

Content permissions control access to Tableau items such as projects, workbooks, views, and published data sources. They determine capabilities such as viewing, editing, downloading, or deleting content.

3.4 Row-level security

RLS restricts the records visible to a user after access to the relevant content has been granted. Two users may have permission to open the same dashboard but receive different data because their security entitlements differ.

3.5 Data-source security

Data-source security protects access to the underlying data connection and may include database credentials, connection permissions, data-source filters, and database-level security rules.

Comparison of the main concepts

4. Why Row-Level Security Is Important

• Data confidentiality: Prevents users from seeing records outside their authorized scope.
• Centralized reporting: Allows different users to use the same dashboard securely.
• Reduced duplication: Reduces the need to create separate workbooks for individual users or regions.
• Improved governance: Helps organizations enforce consistent access policies.
• Controlled self-service analytics: Enables users to explore authorized data without giving everyone unrestricted access.
• Reduced accidental exposure: Helps limit the visibility of sensitive customer, employee, financial, or operational information.

RLS is only one part of a complete security strategy. It should be combined with appropriate content permissions, authentication, data-source protection, and database controls where necessary.

5. How Row-Level Security Works in Tableau

A typical user-based RLS workflow follows these steps:

1. The user signs in to Tableau Server or Tableau Cloud.
2. Tableau identifies the authenticated user.
3. The security rules identify which regions, departments, customers, or other records the user is entitled to access.
4. A security calculation or data policy evaluates the applicable rule.
5. Only rows that satisfy the rule are returned or made available to the user through the secured data access path.
6. The dashboard displays the permitted data.

Example of the workflow

User logs in
    ↓
Tableau identifies the user
    ↓
Security mapping finds authorized region
    ↓
RLS rule evaluates the data
    ↓
Unauthorized rows are excluded
    ↓
User views the permitted dashboard data

The exact enforcement point depends on the chosen design: workbook filters, data-source filters, virtual-connection data policies, or database-native security.

6. Row-Level Security Methods in Tableau

Tableau supports multiple approaches to implementing RLS. The appropriate method depends on the data architecture, number of users, sensitivity of the information, licensing, and administration requirements.

6.1 Manual user filters

Manual user filters associate specific Tableau users with specific data values. For example, an administrator can map a manager to the Mumbai region.

Advantages:

• Relatively simple for a small number of users.
• Easy to understand and demonstrate.
• Useful for small, stable workbooks.

Limitations:

• Requires ongoing maintenance as users or regions change.
• May need to be configured separately for multiple workbooks.
• Can become difficult to maintain in large deployments.

6.2 Dynamic user filters

Dynamic user filtering uses a calculation and security fields in the underlying data to determine what a user can see. The calculation typically compares the current Tableau username with a username field in the data or an entitlement mapping.

Advantages:

• Can automatically adapt to changes in the underlying security mapping.
• Can support many users and multiple authorized regions.
• Can be applied at the data-source level to support several workbooks.

6.3 Entitlement-table-based security

An entitlement table maps users or groups to the business data they are permitted to access. For example, it can connect usernames to region codes, department IDs, customer IDs, or employee IDs.

This approach is particularly useful when one user can access several regions or when multiple users share the same access rights.

6.4 Virtual connections and data policies

In supported Tableau environments, virtual connections with data policies provide a centralized approach to applying RLS. A data policy can filter records for content that uses the secured virtual connection, reducing the need to reproduce the same security rule in every workbook. Availability depends on the applicable Tableau product and Data Management licensing.

Official reference: Tableau Virtual Connections and Data Policies.

6.5 Database-native row-level security

Some databases can enforce row-level security directly. In this design, database policies restrict the rows a database user or session can query. This can be useful when multiple applications access the same secured data.

Database-native security must be designed carefully with Tableau's connection and credential model. If all Tableau users query the database using one shared service account, the database may not automatically identify the individual Tableau viewer. The architecture must reliably pass or establish the correct user context.

Method comparison

7. Important Tableau User Functions for RLS

Tableau provides user functions that can help create user-aware calculations. Always test the actual values returned in your Tableau environment before using a function in a production security rule.

7.1 USERNAME()

USERNAME() returns the username associated with the current Tableau user context. It is commonly used to match the logged-in user with a username field in a security mapping.

[Username] = USERNAME()

Example: If the current Tableau username is [email protected], rows whose security mapping username matches that value satisfy the condition.

7.2 FULLNAME()

FULLNAME() returns the full name associated with the current Tableau user context. It may be useful when the security field stores matching display names. Usernames or stable IDs are generally preferable for security mappings because display names may not be unique and may change.

[Salesperson] = FULLNAME()

Use this comparison only when the values in the data are intentionally aligned with the full names returned by Tableau.

7.3 ISMEMBEROF()

ISMEMBEROF() checks whether the current user belongs to a specified Tableau group.

ISMEMBEROF("Regional Managers")

The result can be used in a calculation or filter to support group-based access logic. Confirm the exact group name and user membership in the target site.

7.4 Combining conditions

Security conditions can combine multiple checks using logical operators such as AND and OR. For example, a rule may allow users to see their own records or allow members of an approved administrator group to see all records in a particular dataset.

[Owner Username] = USERNAME()
OR ISMEMBEROF("Approved Data Administrators")

Important: A calculation is not secure merely because it looks correct. It must be applied at a reliable enforcement point, tested against real user identities, and protected against users removing or bypassing the rule.

8. Creating Row-Level Security with a Username Field

This example demonstrates the basic idea of filtering rows based on the logged-in user's identity.

Step 1: Prepare the dataset

Assume the sales dataset contains the following fields:

In this simplified example, each row is assigned to one username. In a real business dataset, the username mapping may instead be stored in a separate entitlement table.

Step 2: Connect to the data in Tableau Desktop

1. Open Tableau Desktop.
2. Connect to the database, spreadsheet, or other supported data source.
3. Confirm that the dataset includes the required username or security mapping field.
4. Check the username values for spelling, duplicates, missing values, and consistency.

Step 3: Create a calculated field

1. Open a worksheet.
2. In the Data pane, select the option to create a calculated field.
3. Name the field RLS - Current User Match.
4. Enter the following formula:

[Username] = USERNAME()

The expression returns a Boolean result. It is TRUE when the row's username matches the current Tableau username and FALSE otherwise.

Step 4: Apply the security filter

1. For a basic demonstration, drag the calculated field to the Filters shelf.
2. Select True.
3. Build a simple table or chart using the sales data.
4. Verify that only matching records appear for the current user.

Production guidance: A worksheet-level filter is not sufficient if users can edit the workbook or remove the filter. For stronger workbook-level protection, consider enforcing the rule through a suitably secured published data source, a supported virtual-connection data policy, or database security. Review the permissions that users have over the workbook and underlying data.

Step 5: Validate the result

Test the published content using accounts with different usernames. Confirm that each account sees the expected records and that unauthorized records cannot be recovered through other views, downloads, or accessible data paths.

9. Dynamic RLS Using an Entitlement Table

An entitlement table stores the relationship between users and the data they are allowed to access. This is useful when a user can access more than one region or when many users share the same regional permissions.

Example sales table

Example entitlement table

How the mapping works

According to the entitlement table, Amit can access Mumbai and Pune, Neha can access Delhi, and Rahul can access Pune. Amit's access is not limited to a single region, because the table contains two entitlements for his username.

Implementation procedure

1. Prepare a sales table and a separate entitlement table.
2. Ensure that the entitlement table contains the correct user identifiers and allowed region values.
3. Relate or join the entitlement data to the sales data using the appropriate region key, and ensure that the current user's entitlement is applied correctly.
4. Create a calculation that compares the entitlement username with the current Tableau username.
5. Apply the user-matching rule at an appropriate data-source or policy level.
6. Test users with one entitlement, multiple entitlements, and no entitlements.

For example, a conceptual matching condition is:

[Entitlement Username] = USERNAME()

This expression identifies the entitlement rows associated with the current user. The actual data model must also ensure that only sales rows matching those entitlements remain visible. Do not assume the username comparison alone filters the sales table correctly unless the relationships, joins, and filter placement have been configured and verified.

Best practices for entitlement tables

• Use stable, unique user identifiers wherever possible.
• Use consistent region codes or other keys rather than relying on inconsistent text labels.
• Remove duplicate mappings where they are not meaningful.
• Define how missing or unmatched entitlements should behave.
• Keep entitlement data current when users transfer teams or leave the organization.
• Restrict access to the security mapping itself if it contains sensitive information.
• Review joins and relationships carefully to avoid duplicate sales values or incorrect totals.

Further reading: Tableau Best Practices for Row-Level Security with Entitlement Tables.

10. Applying RLS at the Data-Source Level

A data-source filter can restrict the rows available through a data source. When appropriately configured and secured, it can provide a reusable security layer for multiple workbooks that use the same published data source.

General workflow

1. Connect to the source data in Tableau Desktop.
2. Prepare the username or entitlement mapping.
3. Create and test the user-based security calculation.
4. Configure the filter at the data-source level, selecting only the permitted result.
5. Publish the data source to Tableau Server or Tableau Cloud.
6. Set suitable permissions so users can access the published source without being able to remove or bypass the security logic.
7. Connect authorized workbooks to the published data source.
8. Test the resulting access with different user accounts.

A separately published and secured data source can be more robust than relying on a filter embedded in a workbook that users can edit or download. However, publishing separately does not automatically make a source secure; its connection permissions, capabilities, credentials, and filter configuration must also be reviewed.

Official guidance: Tableau RLS Best Practices for Data Sources and Workbooks.

11. Row-Level Security with Virtual Connections and Data Policies

Virtual connections can provide a central access point to data. Where the required Tableau features and licensing are available, data policies can apply row-level security at the virtual-connection level rather than requiring every workbook author to configure a separate filter.

Benefits

• Centralized management of security logic.
• Consistent row filtering across supported content that uses the virtual connection.
• Less duplication of security calculations across workbooks.
• Separation of data governance responsibilities from dashboard design.
• Support for security policies with live queries and supported extract-based workflows.

Typical setup process

1. Create a virtual connection to the appropriate data source.
2. Select the tables that need protection.
3. Create a data policy and identify the tables and fields that should be governed.
4. Write a policy condition that evaluates whether each row is allowed for the current user or group.
5. Configure entitlement mappings if access depends on a separate user-to-region or user-to-record table.
6. Validate the policy using test users and representative data.
7. Publish the virtual connection and grant the appropriate connection permissions.
8. Connect workbooks and other supported content to the secured virtual connection.

Tableau data policies are different from workbook permissions: permissions govern access to Tableau content and capabilities, while a data policy filters the records returned through the secured connection. Both controls may be needed.

Read more: About Tableau Virtual Connections and Data Policies.

12. Managing User Roles, Groups, and Permissions

Row-level security should be combined with a clear permission model. Tableau site roles determine a user's maximum capabilities and licensed access, while permissions control capabilities on specific content. Neither should be treated as a replacement for row-level security.

12.1 Site roles

Site roles establish the general level of functionality available to a user. Administrators should assign roles according to job responsibilities and licensing requirements.

12.2 Groups

Groups make it easier to assign permissions to users with similar responsibilities. For example, an organization might maintain groups such as Sales Managers, Finance Analysts, HR Team, and Data Administrators.

12.3 Content permissions

Permissions determine whether users can view, edit, download, publish, or manage specific Tableau content. Configure them on projects, workbooks, views, published data sources, and virtual connections as applicable.

12.4 Least-privilege principle

Give users only the minimum permissions needed for their work. Avoid broad administrator rights or unrestricted download permissions when they are not necessary.

Recommended access model

13. Row-Level Security vs. Workbook Filters

A normal worksheet filter is often used for analysis and presentation. RLS is a security control. The difference is important because a filter that a user can change or remove should not be the sole protection for confidential data.

Do not rely on hiding a field, hiding a worksheet, removing a dashboard filter control, or adding a visual condition as a substitute for properly enforced data security.

14. Data Security for Live Connections and Extracts

RLS design must account for how Tableau accesses and stores data.

Live connections

A live connection queries the underlying data source as needed. Database-native RLS may be useful if the database receives and correctly enforces the appropriate user context. If Tableau uses shared credentials, verify that the database can still distinguish users as intended or use another reliable enforcement layer.

Extracts

An extract is a stored snapshot of data. Security must remain effective when users access the extract through Tableau. An extract should not be treated as secure merely because the original database has row-level security. Verify how the extract is generated, stored, refreshed, published, and accessed.

Important considerations

• Determine whether the selected RLS method supports the connection type and extract model.
• Review who can download data, access underlying data, edit workbooks, or download workbooks.
• Verify that extracts and published data sources do not expose unrestricted records.
• Test security after publishing, refreshing, replacing, or changing the data source.
• Use the relevant Tableau documentation to confirm feature limitations for your version and environment.

Official reference: Restrict Data Access with User Filters and Row-Level Security.

15. Data Access Management Best Practices

• Use least privilege: Grant only the capabilities and data access necessary for each role.
• Prefer dynamic mappings at scale: Use maintainable user or entitlement mappings instead of manually configuring many individual filters.
• Centralize reusable security: Consider a secured published data source or virtual-connection data policy where appropriate.
• Protect security logic: Do not allow ordinary consumers to remove the only filter enforcing access.
• Use reliable identifiers: Prefer stable usernames, IDs, and normalized keys over ambiguous display names.
• Validate group membership: Ensure that group-based rules reference the correct Tableau groups.
• Handle missing mappings safely: Users without a valid entitlement should not accidentally receive unrestricted data.
• Review permissions regularly: Remove outdated access when users change roles or leave the organization.
• Test multiple access scenarios: Include ordinary users, users with multiple entitlements, administrators, and users with no matching records.
• Protect sensitive exports: Review download, web-editing, and underlying-data capabilities.
• Monitor changes: Review security-related changes to workbooks, data sources, user groups, policies, and database permissions.
• Document the design: Record the data owner, policy logic, mapping source, and testing procedure.
• Re-test after changes: Security may be affected by schema changes, new data, altered relationships, or publishing changes.

16. Common Row-Level Security Problems and Solutions

17. Practical Project: Secure a Regional Sales Dashboard

Project objective: Build a Tableau dashboard that allows each regional manager to view only the sales data for their authorized region.

Business requirements

• All regional managers use the same published dashboard.
• Each manager can access one or more assigned regions.
• Users must not be able to access unauthorized regions by changing a worksheet filter.
• Administrators can manage the security mapping.
• The dashboard must be tested before it is made available to business users.

Sample sales data

Sample entitlement data

Project steps

1. Import the sales dataset and entitlement table.
2. Inspect data types and confirm that region values and usernames are consistent.
3. Build the data model so sales rows are associated with the appropriate entitlements without multiplying records.
4. Create a user-based security calculation that identifies the current user's entitlement rows.
5. Configure the rule as a protected data-source filter or another appropriate RLS enforcement mechanism.
6. Create charts for sales by region, product, and order.
7. Build a dashboard with a regional sales summary and product performance view.
8. Publish the data source and workbook with suitable permissions.
9. Test using Amit, Neha, Rahul, and a user without an entitlement.
10. Confirm that Amit can see Mumbai and Pune, Neha can see Delhi, Rahul can see Pune, and the user without an entitlement cannot see unauthorized data.
11. Review download and editing permissions and document the final security configuration.

Expected outcome

The dashboard provides a shared reporting experience while the security layer limits each user to the records authorized by the entitlement mapping. The result should be validated using the actual published environment, not only by previewing a worksheet in Tableau Desktop.

18. Security Testing Checklist

• Confirm that every user has a distinct and correctly configured identity.
• Confirm that usernames match the security mapping exactly.
• Test users with one region and users with multiple regions.
• Test a user with no entitlement mapping.
• Test users who belong to authorized and unauthorized groups.
• Check totals and record counts for unexpected duplication.
• Test the published workbook with ordinary viewer permissions.
• Check whether editing or download capabilities could expose unrestricted data.
• Confirm that all workbooks using the shared source receive the intended security rules.
• Test after changes to the data model, entitlement table, or security policy.
• Review access when users change roles or leave the organization.
• Document test accounts, expected results, actual results, and remediation actions.

19. Interview Questions and Answers

Q1. What is Row-Level Security in Tableau?

Answer: Row-Level Security restricts the rows of data a user can see according to their identity, group membership, or assigned entitlements. It allows different users to use the same dashboard while viewing different authorized records.

Q2. What is the difference between RLS and Tableau permissions?

Answer: Permissions control access to Tableau content and capabilities, such as viewing or editing a workbook. RLS controls which data rows are visible to the user. A secure deployment often requires both.

Q3. What is a user filter?

Answer: A user filter restricts data according to the identity or characteristics of the current Tableau user. It can be manually mapped or dynamically calculated from fields in the underlying data.

Q4. What is an entitlement table?

Answer: An entitlement table maps users or groups to the data values they are authorized to access, such as region codes, department IDs, or customer identifiers.

Q5. What does USERNAME() do?

Answer: It returns the username associated with the current Tableau user context and can be used to match that identity to a security field.

Q6. What does ISMEMBEROF() do?

Answer: It checks whether the current user belongs to a specified Tableau group and can be used in group-based filtering logic.

Q7. Why is a normal worksheet filter not sufficient for security?

Answer: A worksheet filter may be removable or changeable by users with sufficient editing access. Confidential data should be protected by an enforcement mechanism that users cannot bypass through ordinary workbook interactions.

Q8. What is the purpose of a published data source in an RLS design?

Answer: A properly secured published data source can centralize the data model and filtering rules for multiple workbooks. Its permissions and security configuration must prevent unauthorized users from bypassing the intended controls.

Q9. What is the advantage of virtual-connection data policies?

Answer: Where supported, they provide a centralized way to define and apply row-level security to content that uses a virtual connection, reducing duplicated security logic across workbooks.

Q10. What happens when a user has no entitlement mapping?

Answer: The security design should normally deny access to protected rows unless an explicitly approved rule grants access. Missing mappings must be tested rather than assumed to behave securely.

Q11. What is the least-privilege principle?

Answer: Users receive only the minimum content capabilities and data access needed to perform their responsibilities.

Q12. How can you test RLS?

Answer: Test the published content with different user identities, including users with one entitlement, multiple entitlements, no entitlements, and different group memberships. Verify visible rows, totals, downloads, and editing capabilities.

Q13. Can database security and Tableau RLS be used together?

Answer: Yes. A layered approach can combine database-native controls with Tableau permissions and RLS. The design must ensure the correct user context is enforced and that shared database credentials do not undermine the intended policy.

Q14. What is a common cause of incorrect sales totals after implementing RLS?

Answer: Incorrect joins or relationships between the sales table and entitlement table can duplicate fact rows. The data model and aggregation behavior must be tested carefully.

Q15. What is the most important RLS best practice?

Answer: Enforce security at a protected layer, maintain accurate entitlement mappings, use least-privilege permissions, and validate the published solution with representative user accounts.

20. Practice Exercises

1. Create a dataset with sales for three regions and configure a user filter for each regional manager.
2. Build an entitlement table that allows one user to access two regions.
3. Create a calculated field using USERNAME() and test it with different user accounts.
4. Use ISMEMBEROF() to explore a group-based access rule in a controlled test environment.
5. Compare a worksheet filter with a protected data-source filter and document the security differences.
6. Design a test case for a user with no entitlement mapping.
7. Investigate how an entitlement-table join can duplicate sales values and correct the data model.
8. Review a published workbook's permissions and identify capabilities that could allow users to bypass the intended security design.

21. Quick Revision Notes

• RLS controls which data rows a user can see.
• Permissions control what users can do with Tableau content.
• Authentication identifies the user; authorization determines permitted actions.
• USERNAME() can match the current Tableau username with a security field.
• FULLNAME() returns the user's full name in the Tableau context.
• ISMEMBEROF() checks membership in a Tableau group.
• Entitlement tables map users or groups to authorized data values.
• Data-source filters can support reusable RLS when correctly configured and secured.
• Virtual connections and data policies can centralize RLS where the features and licensing are available.
• Database-native RLS is another option, provided the correct user context reaches the database.
• Worksheet filters and hidden fields are not reliable substitutes for security enforcement.
• Always test published content using multiple user identities.
• Review data downloads, editing rights, credentials, mappings, and permissions.

22. Official Tableau Learning Resources

• Restrict Data Access at the Row Level
• RLS Best Practices for Data Sources and Workbooks
• Virtual Connections and Data Policies
• Best Practices for RLS with Entitlement Tables
• Tableau Permissions Overview

23. Conclusion

Row-Level Security and Data Access Management are essential for building secure, scalable Tableau analytics. RLS ensures that users see only the records permitted by their assigned access rules, while Tableau permissions govern access to workbooks, views, projects, and data assets.

For a small deployment, a carefully configured user filter may be sufficient. For larger environments, dynamic security calculations, entitlement tables, secured published data sources, virtual-connection data policies, or database-native security may provide a more maintainable approach. Select the method that fits your data architecture and licensing, enforce it at a protected layer, and test it thoroughly with real user scenarios.

Continue learning: Explore Tableau Training

Get started with a demo: Register for a Tableau Course Demo